@istarkov - this is great, and a good catch. I'll want to add a test for this before release, so hang tight (unless you want to add that to the PR)

I’ve created a simple test to verify that the first argument of the missing function is the request.

I also fixed the StatusError imports because they were not resolved properly when the package was imported, causing all properties of StatusError to have the any type. See the “Should give TypeScript error” comment for more details.

Example:

import { Router, type IRequest } from 'itty-router';

type CFArgs = [Env, ExecutionContext];

const router = Router<IRequest, CFArgs>({
  catch: (error) => {
    // eslint-disable-next-line no-console
    console.error(error);

    error.status satisfies number;
    error.status satisfies string; // <-- Should give typescript error
    
    return new Response(error.message, {
      status: error.status,
    });
  },
});

These errors will be visible if "moduleResolution": "bundler" is set in tsconfig.json under compilerOptions.

Alternatively, with the new module: "preserve" option in TypeScript 5.4, the bundler option will be implied.
Reference: TypeScript Handbook - Module Resolution

Additionally, the baseUrl has been removed.

So, I’ve also updated the tsconfig.json.

Splitted PR on 2 commits instead of 2 PR's.

Also found

• itty-router/src/types/RouterOptions.ts

  Line 13 in 7cb1458

  catch?: ErrorHandler<StatusError, RequestType, Args>

  
  is a wrong type, the error is not formatted to the StatusError type

catch (err: any) {
        if (!other.catch) throw err
        response = await other.catch(err, request.proxy ?? request, ...args)
      }

2 ways to fix, give an unknown type as in modern ts, or fomat error

Taking a dive on this today - we've had a bit of a hurricane rip through this week :D

Interesting test had no issues with [email protected] but fails on [email protected]. Investigating

Fixed.

This is great, thanks for the catch!